In the practical application of Ethernet, various protection technologies are widely used to achieve the redundancy backup between the master path and standby path. One implementing manner is: when both the master path and standby path are intact, the protected data forwarding function of the standby path is blocked and the protected data between networks is transmitted on the master path. Another implementing manner is: when the master path has malfunction, the protected data forwarding function of the standby path is activated and the protected data between networks is switched onto the standby path to transmit to avoid the repeated receipt of the protected data and the formation of broadcast storm under the normal state of the network. This manner of enabling the standby path to transmit protected data when the master path of the network has malfunction can be used to improve the anti-failure capability of the Ethernet and meet the high instantaneity requirements of the convergence time being smaller than 50 ms during the switch. The implementing manner of the Ethernet ring protection technology will now be described in detail hereinafter.
As shown in FIG. 1, all nodes A to F are nodes which possess the Ethernet exchange function, network M is connected to node B, and network N is connected to node D. Network M communicates with network N. There are two physical paths between network M and network N, i.e. network N<->node D<->node C<->node B<->network M; network N<->node D<->node E<->node F<->node A<->node B<->network M. “c” and “w” in FIG. 1 represent the on-ring ports of each node, and different on-ring ports of the same node are represented by “e” and “w” differentially.
When applying the Ethernet ring protection technology, the ring protection link and control node are generally defined, that is, in the situation that the Ethernet ring is not failed, a link on the ring which blocks the data messages so as to prevent the formation of a ring loop is referred to as ring protection link, and the switch between the master path and standby path of the ring network can be performed by operating this section of ring protection link. A node which has a ring protection link is referred to as a control node or a master node here. As shown in FIG. 2, the Ethernet ring includes nodes A, B, C, D, E, and F and links <A, B>, <B, C>, <C, D>, <D, E>, <E, F>, and <F, A>. Node A is a control node or referred to as a master node, and link <F, A> which is directly connected to the port e of node A is a ring protection link.
When the on-ring links are intact, the control node blocks the data message forwarding function of the ports which are connected to the ring protection link, so there is no ring loop generated in the network, which prevents the broadcast storm caused by network ring loop. As shown in FIG. 2, node A blocks the protected data forwarding function of the port e, and the communication path of network M and network N is: network M<->node B<->node C<->node D<->network N, as shown by the heavy solid lines in FIG. 2.
When a link is failed, the control node activates the data message forwarding function of the port connected to the ring protection link, thus ensuring the connection of services. As shown in FIG. 3, link <B, C> on the ring is failed, and node A activates the data message forwarding function of port e, and the new communication path of network M and network N is: network M<->node B<->node A<->node F<->node E<->node D<->network N, as shown by the heavy lines in FIG. 3.
Actually, when the network topology changes, the nodes on the ring network have to refresh the address forwarding table, which is for preventing the data path from propagating along the path before the topology changes. For example, in FIG. 2, there is no failure on the ring network, and the communication path between network M and network N is network M<->node B<->node C<->node D<->network N. When link <B, C> on the ring network is failed, if the communication path between network M and network N still forwards along the original path, a large amount of data messages will be discarded. Currently, the existing solution for refreshing single ring address is: the topology change points periodically send address refresh messages to solve the above problem, which solution for refreshing single ring address will now be described particularly in the following.
When a port of a node on the ring network receives a protocol message which carries the address refresh information, the port will extract <Node_ID, BPR> information from the protocol message. The port compares the <Node_ID, BPR> information in the message with the <Node_ID, BPR> information previously stored in the port. If inconsistent, the port would delete the previously stored <Node_ID, BPR> and store the new <Node_ID, BPR>. If the newly stored <Node_ID, BPR> is inconsistent with the <Node_ID, BPR> stored by another port of this on-ring node, then the node refreshes the address forwarding table, wherein parameter Node_ID in the <Node_ID, BPR> information is the information of the node which sends this protocol message; parameter BPR is used for indicating which on-ring port of this node sending the protocol message is blocked and can also be understood as the information of the port of the node which sends the protocol message, and parameter BPR is only of local meaning, and only represents what port of this on-ring node is blocked and it does not need to number this port globally.
The above solution well solves the problem of repeated refresh caused by periodically sending the message which carries address refresh information, i.e. the problem of the address forwarding table being refreshed repeatedly due to the subsequent address refresh messages. However, this solution is unable to completely eliminate the problem of the address being refreshed repeatedly. As shown in FIG. 4, link <B, C> is failed, node C sends message SF1 along its port w and message SF1 contains <Node_ID (C), e> information; node B sends message SF2 along its port e and message SF2 contains <Node_ID(B), w> information. When receiving message SF1 for the first time, the port e of nodes D, E, F and A on the ring finds that the <Node_ID (C), e> in SF1 is different from the <Node_ID, BPR> stored in their ports e and w, then it refreshes the address forwarding table. Likewise, when receiving message SF2 for the first time, the port w of nodes D, E, F and A on the ring finds that the <Node_ID (B), w> in SF2 is different from the <Node_ID, BPR> stored in their ports w and e, then it refreshes the address forwarding table. It can be seen that after nodes C, D, E, F, A, and B on the ring receive messages SF1 message and SF2 message for the first time, since different ports on the same node (i.e. ports e and w) all have to judge whether to refresh the address forwarding table, the same node needs to refresh the address forwarding table twice at the ports on both sides in the situation that the judgment is passed.
It can be seen from the above example that one topology change on the ring will cause the same node on the ring to refresh the address forwarding table twice in the currently available solution, and this situation will cause the ring network difficult to enter stable state from the broadcast storm state in short time. Moreover, since the protocol message is sent periodically, after nodes C, D, E, F, A, and B on the ring first receive messages SF1 and SF2, they will receive messages SF1 and SF2 regularly and make the same judgment as above, that is, the address forwarding table needs to be refreshed more than once. As to the above problem in the relevant art, no effective solution has been proposed yet.